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REMARKS 

This is intended as a full and complete response to the Final Office Action dated 
January 9, 2004, having a shortened statutory period for response set to expire on April 
9, 2004. Please reconsider the claims pending In the application for reasons discussed 
below. 

Claims 1-20 are pending in the application. Claims 1, 3-17 and 19-20 remain 
pending following entry of this response. Claims 2 and 18 have been canceled without 
prejudice. Claims 1, 4, u, 11, 13, 14, 16 and 17 have been amended. However. 
Applicants submit that the amendments merely clarify, rephrase and/or restructure what 
was already recited. For example, claims 6 and 16 are amended to recite that input 
field information represents "a given one of at least two request types' of a request 
message format, which merely rephrases the original language that, in a given instance, 
the input field information s specific to only one request type, but avoids constructing 
the "input field information" as being limited to a particular request type (e.g., purchase 
order) in every instance. Claim 13 is similarly amended with respect to the output field 
information and is further amended to recite that the request type represented by the 
output field information is ihe same as the request type represented by the input field 
information, thereby making claim 13 conform to original claim 16 in this respect. 
Accordingly, none of the amendments can be considered new matter. Further, claims 1 
and 16 are amended to recite aspects previously recited in claims 2 and 18, 
respectively. 

Claims 1 - 20 stanc rejected under 35 USC § 102(e) as being anticipated by 
Ankireddipally et al. (US 2002/0116205, hereinafter Ankireddipally). Applicants 
respectfully traverse the rejection. Withdrawal of the rejection is respectfully requested. 

Applicants hereby Ir corporate their Response filed on October 31, 2003 in its 
entirety. In addition, Applicants make the following arguments. 

Fundamentally, Applicants respectfully submit the Examiner misconstrues 
Ankireddipally. Regarding claim 1, for example, the Examiner refers to paragraph 0047, 
lines 5-15 as disclosing a dsita structure defining a message format for a particular 
eCommerce transaction typ.3. However, this passage refers to the "basic transport 
assumption" of Ankireddipally and states that "...the present implementation of CXIP is 
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based on TCP/IP." TCP/IP is a well-known transport protocol and persons skilled in the 
art will therefore recognize! that the passage clearly deals with issues of transferring 
data from one network location to another and does not elaborate at all on types of 
transactions and/or the interfaces used by those transactions to exchange data. 

The Examiner further references paragraph 0043, lines 3-11 as describing a 
request message format consisting of a plurality of fields where input field information is 
at least a portion of the plu -ality of fields. Claim 1 refers to a "data structure configured 
as an interface definition of a message format...comprfs!ng: protocol information 
identifying a protocol and the particular eCommerce request type; request data format 
information.. .wherein the request message format comprises a plurality of input fields; 
and input field information...". The XML message referenced in the cited passage of 
Ankimddipally does not mske any reference to the particular protocol (e.g. cXML, 
mXML), transaction type (e .g. purchase order, advanced shipping notice) nor does it 
describe the incoming requ sst data as a set of discrete fields. The cited passage of 
Ankireddipally does refer to a "message type" attribute that is used to "manage 
message type sequencing imd timing". Examples of message type include Request, 
Reply, and Cancel. However, these refer to the interaction model between two 
applications (e.g., who initiates the transaction and whether they can expect to receive a 
response) and does not ide itify a particular eCommerce protocol (e.g. , cXML) nor a 
particular request type (e.g. a purchase order). 

In response to Applicants' argument in their Response of October 31 , 2003 that 
the referenced passage dei?ls with data transport issues, the Examiner states that 
paragraph 0041, lines 1-10 and paragraph 0042 in combination define a transaction^ 
oriented protocol which anticipates the present claims. Applicants disagree. The first 
cited passage concerns "...exchanging messages in the form of XML documents." The 
second cited passage stater; that "the CXIP application interaction protocol supports 
three of the most common types of application interaction models... request/reply, 
publish/subscribe and broadcast." Together, these define a "protocol" for 
representation of data exchs nged (XML) and for the type of call/return semantics to be 
used (request/reply, publish/subscribe, broadcast). Accordingly, this "protocol" does not 
describe an eCommerce protocol (e.g. cXML), an eCommerce request type (e.g. 
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purchase order), r quest ri tessag format information and Identification of the data 
fields being provided as input. 

Regarding claim 16 the Examiner refers to some of the same passages that were 
referred to with respect to claim 1 and additionally to paragraph 0059, line 1-9, 
paragraph 0065, lines 15-25 and paragraph 0074, lines 5-13. Claim 16 recites "...a data 
structure configured as an nterface definition of a request message format and a 
response message format <rf a particular eCommerce request type.." and "input field 
information" and "output fie? Id information", where the former is associated with the input 
provided with one or more request types and the latter is associated with the output 
generated for one or more request types. The first cited passage refers to "message 
types associated with a transaction instance". The message types are defined as 
"transaction request message, operation request message, operation response 
message and transaction response message." These refer to messages processed by 
the transaction service at different points within a given transaction lifecycle and do not 
indicate the protocol or tran saction type (e.g. cXML, purchase order) nor the set of input 
and output data fields required by the given protocol/transaction type. Paragraph 0065, 
lines 1 5-25 refers to components describing the DAG that defines the flow of operations 
defined to service a given request. This is not at all related to the concepts of an 
interface definition for request and response message formats. Paragraph 0074, lines 
5-13 refer to the internal operation of the CX server component of Ankireddipatly and 
how the CX server passes n n incoming request to the transaction service for 
processing. Again, this is not concerned with the issues of overall request and 
response interface definition s that is the subject of claim 1 6. 

Perhaps most significantly, Ankireddipatly does not provide for "input field 
information identifying at least a portion of the plurality of input fields and identifying a 
physical location, in a request message having the request message format, of each 
input field of at least the portion of the plurality of input fields". (See, claim 1 .) Nor does 
Ankireddlpally provide for "output field information identifying at least a portion of the 
plurality of output fields and identifying a physical location, in a response message 
having the response messa*: e format, of each input field of at least the portion of the 
plurality of output fields". Th s aspect of the present claims allows r quests and 
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responses to be abstracter! from specific applications handling the request and issuing 
the responses. In contrast, Ankireddipally presumes that the application logic in 
question is structured to deal with a DOM representation of the input data required by 
and output data generated by the application. As such, the CXIP message of 
Ankireddipally would not include input/output information mapping into incoming 
messages since the struck-re of the message is known. In this regard, Applicants again 
emphasize a significant misunderstanding on the part of the Examiner, the 
Ankireddipally data structur e referred to bv the Examiner is the eCommerce massag e 
itself. In contrast, the clajp- ed data structure provides input/output information which 
identifies (i.e.. maps into) tir e physical location of fields in eCommerce messages. 
Thus, the claimed data structure is not the eCommerce message itself. 

For each of the forecolnq reasons. Applicants submit that Ankireddipally doe* nnt 

teach, show or suggest the data s tructure of the present claims. Accordingly. 
Applicants believe the claims are allowable and respectfully request allowance of trip 
same. 

The secondary references made of record are noted. However, it is believed that 
the secondary references iire no more pertinent to the Applicants disclosure than the 
primary references cited in the office action. Therefore, Applicant believes that a 
detailed discussion of the secondary references is not necessary for a full and complete 
response to this office action. 

Having addressed a I issues set out in the office action. Applicant respectfully 
submits that the claims are in condition for allowance and respectfully request that the 
claims be allowed. 

Respectfully submitted, 

B. Todd Patterson 
Registration No. 37,906 
Moser, Patterson & Sheridan, L.l.p. 
3040 Post Oak Blvd. Suite 1500 
Houston, TX 77056 
Telephone: (713)623-4844 
Facsimile: (713)623-4846 
Attorney for Applicant(s) 
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